The invention relates generally to automatic data collection (xe2x80x9cADCxe2x80x9d) devices and more particularly to receiving instructions from ADC data consumers regarding data output, including instructions specifying a data output mechanism and specifying the characteristics of the data to be routed through the selected data output mechanism.
Automatic Data Collection (xe2x80x9cADCxe2x80x9d) device platforms, such as ADC device platforms equipped with bar code readers, have received increasing commercial attention in the past few years. ADC device platforms, such as handheld data collection terminals, or hand-held personal computers, have been widely implemented in the retail marketplace and have garnered increasing utilization in a diverse range of application areas. The ever-decreasing cost and size of ADC device platforms has facilitated their entry into a wide variety of commercial, institutional, and governmental settings.
An ADC device platform having a bar code reader adeptly accesses and retrieves data stored in the form of a bar code label. Data representing virtually any product or service found in the stream of commerce may be encoded in a bar code label for later access by an ADC device platform having a bar code reader. Bar code readers include laser scanners as well as other means of collecting product information, such as a bar code wand, a still camera or an area imager. In addition to bar code labels, other ADC data formats include Radio Frequency (xe2x80x9cRFxe2x80x9d) tags, resonators, SmartCards, magnetic strips, Optical Character Recognition (xe2x80x9cOCRxe2x80x9d), speech input, two-dimensional (xe2x80x9c2Dxe2x80x9d) symbols, dipole devices (such as those recited in U.S. Pat. No. 5,581,257), and any symbol having encoded data therein.
In a conventional ADC device platform environment, the recipient of ADC data either physically manipulates the ADC device platform itself to retrieve the ADC data or receives the ADC data through a local, and probably proprietary, network. Thus, a typical ADC device operator is limited both in terms of the distance from which the operator may be located away from the actual device and by the complexity and versatility of the elements that comprise the ADC device network which the operator utilizes. The operator suffers from still further limitations due to the fact that many conventional ADC device platforms are not readily configurable for new ADC devices, or even for ADC devices other than those attached to the ADC device platform when it is initially sold. Yet another limitation in a conventional ADC device platform arises when an operator wishes to add a new ADC device to one of the few ADC device platforms that will accept new ADC devices. This limitation stems from the fact that many ADC devices require proprietary communications protocols, and even when the communications protocols are non-proprietary, the communications protocols are typically non-standard. Thus, the operator cannot simply attach a new ADC device to an existing ADC device platform and expect that the new combination will function properly. Finally, the above limitations, both separately and together, hinder an ADC operator""s ability to customize the ADC device platform to operate in the most productive possible manner.
Input data received by an ADC device platform must be routed to the intended destination. Conventional ADC device platforms typically have a simple connection that routes one type of data from a single ADC device to a single destination, typically an application program. However, ADC data consumers presently demand sophisticated and customizable ADC device platforms. In addition, consumers expect their ADC device platforms to be reconfigurable for new ADC devices and new data-receiving applications. Many ADC data consumers also need their ADC device platform to process ADC data without requiring modification of destination applications, which are frequently provided by third parties and cannot be modified without the cooperation and permission of the producer and owner.
A single ADC device may transmit data having a variety of characteristics into an ADC device platform. As ADC device platforms become more adept at receiving data from a variety of ADC devices, efficient mechanisms for routing ADC data become increasingly critical to the overall success of the ADC device platform. Moreover, an application program may request ADC data having characteristics that may potentially arise in the ADC data retrieved by more than one ADC device. While routing decisions may be permanently fixed in an ADC device platform""s basic design, such an approach provides only minimal flexibility and does not accommodate the addition of new ADC devices and new applications.
In prior art ADC device platforms, the ADC device platform typically receives input data from a single ADC device, performs minimal processing on the data, then routes the data to a single destination application. While this design might have been adequate in the past, this design is wholly deficient for the modern data collection environment in which multiple ADC devices provide data to an ADC device platform that then forwards the data to one or more applications. In addition, different applications, for a variety of reasons, may operate more efficiently when they receive data from one particular output mechanism as opposed to another output mechanism. Accordingly, ADC data consumers require increased flexibility regarding the output mechanism available for data output from an ADC device platform.
The invention provides a method and system for receiving a client""s instructions with regard to routing data to the client from one or more automatic data collection (xe2x80x9cADCxe2x80x9d) devices in an ADC device platform.
An aspect of the invention allows client applications to register a request ADC data type in a grid that operates as a data filter. For example, a client may use the grid to request all ADC data received from any ADC device on an ADC device platform when the ADC data has been encoded in a particular data type. Similarly, a client may request one or more data types that may be produced by a specific ADC device.
Another aspect of the invention provides a data transfer mechanism that performs simultaneous data transmission from an ADC device platform over different output mechanisms to reach multiple clients. Clients, residing either on the ADC device platform or on a remote computing system, register with a data output grid to receive data via a particular output mechanism. Following registration of a client""s preferred output mechanism, a data transfer mechanism forwards all data received by the ADC device platform to the client using the output mechanism specified in the data output grid. Using the data transfer mechanism, the same set of input data, destined for more than one application, may be simultaneously transmitted to different output mechanisms. Thus, the data transfer mechanism eliminates a potential data communications bottleneck in a multiple client environment. The invention may utilize an unlimited number of data output mechanisms, including pipes, remote procedure calls (xe2x80x9cRPCxe2x80x9d), sockets, stream files, the network Basic Input/Output System (xe2x80x9cNetBIOSxe2x80x9d), mail slots, the network Dynamic Data Exchange (xe2x80x9cNetDDExe2x80x9d), and shared memory.
ADC devices accommodated by the invention include bar code readers, speech recognition systems, RF tag readers, resonators, SmartCards, two-dimensional data readers, ASCII data devices, AIMI-EIC data devices, dipole device readers, and optical character recognition (xe2x80x9cOCRxe2x80x9d) systems. The invention further allows the updating of existing data output grids or the addition of new information in data grids in association with a newly added ADC device, a newly added output condition, or a newly added client. Similarly, the invention allows the data output grid to be modified to accept a new ADC device, a new output mechanism, or a new client.